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Proposed Change in IMP-to-Host Protocol 


We are currently considering a redefinition of the IMP-to-Host 
error message types (type 1 and type 8) and the creation of addi- 
tional IMP-to-Host error message types. We believe that these 
changes will assist the Hosts in determining appropriate recovery 
action, without causing any serious reprogramming problems. Our 
current plans are to install these changes within a few months; 
therefore we should be informed of any strong negative reactions 
relatively quickly. 


The proposed changes fall into two general classes as de- 
scribed below: 


A) General Error Message 


Under certain circumstances, particularly when the Host 
has been unresponsive to queued input for a "long time" 
the IMP drops its ready line for a short period, causing 
the "error flip-flops" to be set (see RFC #270, NIC 7818). 
Under these conditions the IMP sends a few NOP’s to the 
Host and then resumes normal operation. We propose to 
send the Host a new message (message type 13) in addition 
to the NOPs; this message will tell the Host that the 
IMP’s Ready Line was dropped, that the IMP’s error flop 
was set, and that the IMP will respond to the next com- 
pletion of a Host-to-IMP message with a type 1 or type 8 
message (because of the setting of the IMP’s error flop. 


B) Error Messages which are Responses to Specific 


1) IMP-to-Host message type 1 will be redefined to mean: 
"IMP’s Error flip-flop was set on a message which 
the IMP cannot identify." 


2)  IMP-to-Host message type 8 will be redefined to mean: 
"IMP’s Error flip-flop was set during receipt of the 
message identified by the ’source’ and ’link number’ 
bits of this error message." 
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3) IMP-to-Host message type 10 will be defined to mean: 
"A Host-to-IMP message was too short (and cannot be 
identified) ." 


4)  IMP-to-Host message type 11 will be defined to mean: 
"A Host-to-IMP message was too long; the message is 
identified by the ’source’ and ’link number’ bits 
of this error message." 


5) IMP-to-Host message type 12 will be defined to mean: 
"A Host-to-IMP message with an illegal message type 
code was received; the message is identified by the 
‘source’ and link number’ bits of this error message. 
(Note that the erroneous type code is not included in 
the error message.)" 
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